In computer related industries, software tends to be rapidly evolving. Oftentimes, it is beneficial and/or necessary to provide documentation that describes certain aspects of software to enable a user to utilize the software. Documentation can be any communicable material (e.g., text, video, audio, . . . ) employed to explain various attributes of an object, a system or a procedure. According to an example, documentation can be presented to a user as printed books or computer readable files (e.g., HTML pages). The documentation, for instance, can describe the operation of a system by providing examples, parameters, descriptions of outputs, exceptions, requirements, security parameters, syntax, semantics, error codes, ranges, etc.
Traditionally, technical writers review source code and specifications and generate documentation based upon their evaluations. Commonly there is a limited amount of time between the completion of software and its release to customers during which the technical writers document the software. Moreover, some software can include many millions of lines of source code to be documented. Due to time and/or resource constraints, technical writers frequently fail to document software well and regularly omit critical aspects such as security and error handling. Additionally, technical writers oftentimes publish inaccurate and/or misleading information because the code has changed subsequent to their evaluation. Also, technical writers may be unable or limited in their ability to create documentation under certain circumstances, such as if they lack access to the source code and instead inspect object code, binary instruction sets, etc.
Conventional techniques utilized to generate documentation typically require a programmer or developer to include an indicator or description (e.g., English (or any other suitable language) description explaining aspects of the code populated by the user, . . . ) with the programmed code related to the developed software; additionally, the indicators or descriptions can be output and utilized as the documentation. Accordingly, these conventional generation techniques present deficiencies similar to those yielded by technical writers since the indicators or descriptions may fail to be included with the programmed code and/or may not be updated to account for subsequent alterations of the code because the programmers or developers provide the content of the indicators or descriptions.
Additionally, software programmers can be affected by the aforementioned deficiencies associated with the documentation. For instance, programmers writing secure code typically need to know the permissions associated with a called method. Generally, this information is not available in software application programming interface (API) documentation. Additionally, if this information is available, it can be outdated and, therefore, inaccurate. By way of illustration, a programmer can produce code that writes to a log file. If a log file does not currently exist, the code can provide for the creation of a new log file, which can require proper permissions. If the documentation is incomplete and/or inaccurate regarding these permissions and the programmer is not familiar with the required permissions, then the programmer's code can fail. Moreover, incomplete and/or inaccurate documentation, for example, can lead to development of code that can be maliciously exploited by a hacker who takes advantage of the improper utilization of permissions associated with the creation of the log file and/or the failure to create a log file. Incomplete and/or inaccurate information presented in the documentation can yield several negative repercussions such as undermining customer trust, slowing adoption of new software, and reducing the security associated with software. In view of the above, there is a need to improve documentation generation.